As shown in FIG. 1, a distributed networking environment 1 consists of two or more nodes A, B, C, connected through a communication link or a network 3. The network 3 can be either a local area network (LAN), or a wide area network (WAN).
At any of the nodes A, B, C, there may be a processing system 10A, 10B, 10C, such as a workstation. Each of these processing systems 10A, 10B, 10C, may be a single user system or a multi-user system with the ability to use the network 3 to access files located at a remote node. For example, the processing system 10A at local node A is able to access the files 5B and 5C at the remote nodes B and C, respectively.
Within this document, the term "server" will be used to indicate the processing system where the file is permanently stored, and the term "client" will be used to mean any other processing system having processes accessing the file. It is to be understood, however, that the term "server" does not mean a dedicated server as that term is used in some local area network systems. The distributed services system in which the invention is implemented is truly a distributed system supporting a wide variety of applications running at different nodes in the system which may access files located anywhere in the system.
As mentioned, the invention to be described hereinafter is directed to a distributed data processing system in a communication network. In this environment, each processor at a node in the network potentially may access all the files in the network no matter at which nodes the files may reside.
Other approaches to supporting a distributed data processing system are known. For example, IBM's Distributed Services for the AIX operating system is disclosed in the aforementioned U.S. Pat. No. 4,887,204. In addition, Sun Microsystems has released a Network File System (NFS) and Bell Laboratories has developed a Remote File System (RFS). The Sun Microsystems NFS has been described in a series of publications including S. R. Kleiman, "Vnodes: An Architecture for Multiple File System Types in Sun UNIX", Conference Proceedings, USENIX 1986 Summer Technical Conference and Exhibition, pp. 238 to 247; Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem", Conference Proceedings, Usenix 1985, pp. 119 to 130; Dan Walsh et al., "Overview of the Sun Network File System", pp. 117 to 124; JoMei Chang, "Status Monitor Provides Network Locking Service for NFS", JoMei Chang, "SunNet", pp. 71 to 75; and Bradley Taylor, "Secure Networking in the Sun Environment", pp. 28 to 36. The AT&T RFS has also been described in a series of publications including Andrew P. Rifkin et al., "RFS Architectural Overview", USENIX Conference Proceedings, Atlanta, Ga. (June 1986), pp. 1 to 12; Richard Hamilton et al., "An Administrator's View of Remote File Sharing", pp. 1 to 9; Tom Houghton et al., "File Systems Switch", pp. 1 to 2; and David J. Olander et al., "A Framework for Networking in System V", pp. 1 to 8.
Some of the problems which are encountered in accessing data at remote nodes can be better understood by first examining how a prior art distributed data processing system uses files. As taught by U.S. Pat. No. 4,877,204, filed Feb. 13, 1987, files stored at a server node can be accessed by processes running on remote client nodes. In order to synchronize and coordinate the use of a file by multiple clients, locking facilities are provided that work in such a distributed data processing system. By locking a file a process indicates its intention to make use of the file. In practice there are various kinds of file locks, such as locks indicating a desire for exclusive access, locks indicating a desire for shared access, locks on portions of the file, and locks on the entire file. Because multiple clients may be using a single file, the data structures describing the locks that have been placed are kept at the server when there is the possibility that multiple clients actually will be using the file. In the case where it is clear that a single client is the only user of the file the data structure describing the locks can be kept at that client. In the prior art this determination of where this data structure is located is made based on the processes that have the file open. Before a lock can be placed on the file, a process must have their file open. Therefore, when all of the processes that have the file open are located at a single node, the data structure describing locks on that file is kept at that node.
A difficulty with this prior art approach results from the fact that this determination is based upon which processes have the file open. In situations in which a file is shared by multiple clients, the data structures describing the locks will always be kept at the server despite the fact that only one process at a time actually has an interest in locking the file. A further difficulty is introduced by the need to relocate the data structures describing the locks at the time a process at a different client opens the file. Due to resource limits at the server, it may be impossible to move the data structure back to the server at the time of this open. When this occurs, either locking information must be lost (a very undesirable alternative) or the open operation must be refused (a situation that few applications are prepared to deal with).
As taught by the prior art, requests for locks are sent to the server when the data structures describing the locks reside at the server. These requests are executed by a kernel at the server. A kernel process is a process which has access to the operating system's data including the data structures describing the locks. When a lock request cannot be granted due to conflicting locks already in place, most lock operations are designed to wait until the blocking locks are released and the requested lock can be put in place. The problem with the technique used by the prior art is that a kernel process (kprocs) must wait at the server until the blocking locks are released. Kprocs consume resources at the server and, consequently, are limited in number. By forcing a kernel process to be idle in the presence of blocking locks, the design is more susceptible to exhaustion of all available kprocs. In an application in which processes of several clients are accessing a shared file, if one process locks the file and then, due to user error or a software error, fails to unlock the file a large number of kprocs may be tied up indefinitely. In extreme circumstances all available kprocs might be occupied in this manner to the extent that the system would not be able to support any more remote operations.
It would, therefore, be of great benefit in a distributed data processing system to provide a system and method for locking remote files that does not locate the data structures describing the locks for a file based on the processes having the file open and, further, does not require kprocs to wait when there are blocking locks.